REMARKS 

The Office Action dated February 21, 2008 has been received and carefully noted. 
The above amendments to the claims, and the following remarks, are submitted as a full 
and complete response thereto. 

Claim 16 has been amended to more particularly point out and distinctly claim the 
subject matter of the invention. No new matter has been added and no new issues are 
raised which require further consideration or search. Claims 1-18 are respectfully 
submitted for reconsideration. 

The Office Action indicated that claims 16 was objected to for containing a minor 
informality. Applicant has amended claim 16 to remove the redundant word "are" from 
the claim recitations. Withdrawal of the rejection of claim 16 is respectfully requested. 

Claims 15-16 were rejected under 35 U.S.C. §102(e) as being anticipated by Lord 
et al. (US 6,763,012 - hereinafter Lord). The rejection is respectfully traversed as 
follows. 

Claim 15 is directed to an apparatus that includes a plurality of transmission units, 
where each of the transmission units are configured to communicate with a network 
device using a single packet data context and where each of the transmission units has a 
unique internet protocol address. 

Claim 16 is directed to an apparatus that includes a plurality of transmission 
means for communicating information in a communications network, where each of the 
transmission means are configured to communicate with a network device using a single 
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packet data context and where each of the transmission means has a unique internet 
protocol address. 

The Office Action alleged that Lord discloses all of the subject matter recited in 
claims 15-16, and relied on FIGS. 1-5, the Abstract, and columns 2-4 of Lord as allegedly 
providing support for the features recited in claims 15-16 of the present application. 
Applicant respectfully disagrees that Lord teaches the subject matter recited in claims 15- 
16. 

Lord is directed to a general packet radio service (GPRS) network that includes a 
mobile terminal (MT) and a plurality of user equipment devices (UE) that connect to the 
GPRS network through the MT. The problem identified by Lord's disclosure is the lack 
of unique IP addresses per UE devices during a single cellular connection between a MT 
and a GPRS network (see column 1, line 52 - column 2, line 5 of Lord). There is no 
discussion regarding the need or implementation of a single packet data protocol (PDP) 
context for more than one UE device. Applicant submits that Lord fails to disclose "a 
plurality of transmission units. . . each of the plurality of transmission units are configured 
to communicate with a network device using a single packet data context ", as recited, in 
part, in claim 15 and similarly in claim 16. (Emphasis added) 

Referring to column 2 of Lord, there are two embodiments discussed briefly with 
regard to assigning multiple IP addresses to UE devices that connect to a GPRS network 
via a MT. The first embodiment describes how the MT receives a plurality of IP 
addresses from a packet data network (PDN). The first embodiment does not disclose 
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that a single PDP context is used for more than one UE devices. The second embodiment 
describes how "a separate PDP context" is used for "each device on the LAN" (see 
column 2, lines 33-34 and lines 50-52). The second embodiment is clearly contrary to 
the subject matter recited in claim 15, which recites " using a single packet data context ." 

Referring to column 4 of Lord, a connection procedure is described that includes 
"a single PDP Context activation procedure" (see column 4, lines 25-27 of Lord). The 
PDP context activation procedure establishes a PDP context for the MT and not the user 
equipment (see column 4 5 lines 37-40 and lines 62-67, and column 4 line 67 - column 5 
line 2 of Lord). The PDP context activation procedure is established with the MT and the 
procedure does not include a establishing a single PDP context with a plurality of UE 
devices such that the plurality of UE devices are configured to communicate with a 
network device using a single packet data context. Lord simply does not establish that 
one single PDP context is used for more than one UE device to communicate with the 
MT. 

Lord further discloses that for a GPRS type of system, a one-to-one relationship is 
established with respect to the number of PDP contexts set up per number of UE devices 
(see column 5, lines 54-60). The type of GPRS system disclosed by Lord is what is 
described by the prior art of the present application (see page 1, line 3 1 - page 2 line 5 of 
the present application). Lord does not address a single PDP context for a plurality of UE 
devices. Lord fails to disclose "a plurality of transmission units. . .each of the plurality of 
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transmission units are configured to communicate with a network device using a single 
packet data context", as recited, in part, in claim 15 and similarly in claim 16. 

Therefore, for at least the reasons stated above, Lord fails to disclose all of the 
subject matter recited in independent claims 15-16. Withdrawal of the rejection of claims 
15-16 is kindly requested. 

Claims 1-7, 9, 11-13 and 17-18 were rejected under 35 U.S.C. § 103(a) as being 
anticipated by Lord et al. (US 6,763,012 - hereinafter Lord). The rejection is respectfully 
traversed as follows. 

As stated in detail above, Lord does not discloses that a single packet data context 
is used with more than one IP address of a corresponding plurality of participants. Lord 
does not teach "activating a packet data context for data transmission between identified 
participants . . . associating one packet data context with all of the internet protocol 
addresses of the participants ", as recited, in part, in claim 1. In addition, Lord also does 
not disclose "wherein the first unit and the second unit are configured to associate one 
packet data context with all of the internet protocol addresses of the participating units ", 
as recited, in part, in claim 1 1 . The teachings of Lord do not disclose the above noted 
features of claims 1 and 1 1 . 

Therefore, the subject mater disclosed in Lord does not teach all of the features 
recited in claims 1 and 1 1, and for at least that reason a prima facie case of obviousness 
has not been established with respect to claims 1 and 11. By virtue of dependency, Lord 
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also fails to render obvious the subject matter recited in claims 2-7, 9, 12-13 and 17-18. 
Withdrawal of the rejection of claims 1-7, 9, 11-13 and 17-18 is respectfully requested. 

Claims 8 and 14 were rejected under 35 U.S.C. § 103(a) as being unpatentablve 
over Lord in view of Ravishankar et al. (US 2003/0060210 - hereinafter Ravishankar). 
The Office Action stated that Lord fails to teach or suggest one packet data context for 
one quality of service, and then relied on Ravishankar to disclose such a feature. This 
rejection is respectfully traversed and reconsideration is requested. 

As presented above, Lord fails to disclose or suggest each limitation of claims 1 
and 11, from which claims 8 and 14 depend. Similarly, a combination of Lord and 
Ravishankar fails to disclose or suggest each limitation of claims 8 and 14 because 
Ravishankar fails to remedy the deficiencies of Lord. 

Ravishankar discloses a method and system for providing communications 
services. In one embodiment, a type of communications service present in a 
communications session is determined based on quality of service (QoS) parameters 
assigned for the communications session. The quality of service parameters then are 
adjusted based on a different type of communications service requested. The types of 
communications services include real-time (e.g., a voice over Internet protocol, VoIP, 
video/audio on demand, etc.) and non-real-time (e.g., data, web browsing, FTP, etc.) 
communications services. The services are provided in a communications system, such 
as a general packet radio service (GPRS) communications system 
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However, Ravishankar fails to disclose or suggest, at least, "activating a packet 
data context for data transmission between identified participants... associating one 
packet data context with all of the internet protocol addresses of the participants ", as 
recited, in part, in claim 1, from which claim 8 depends, and similarly recited in claim 11. 
Because Ravishankar fails to cure the deficiencies of Lord with respect to claims 1 and 
11, Ravishankar also fails to teach all of the subject matter recited in claims 8 and 14 
which depend on claims 1 and 1 1, respectively. 

Therefore, it is respectfully requested that the rejection be withdrawn because the 
combination of Lord and Ravishankar fails to disclose or suggest all of the elements of 
any of the presently pending claims. 

Claim 10 was rejected under 35 U.S.C. §103(a) as being unpatentablve over Lord 
in view of Kumaki et al. (US 2002/0191562 - hereinafter Kumaki). The Office Action 
stated that Lord fails to teach or suggest a mobile station sending a request for releasing 
the IP address, and then relied on Kumaki to disclose such a feature. 

As presented above, Lord fails to disclose or suggest each limitation of claim 1, 
from which claim 10 depends. Similarly, a combination of Lord and Kumaki fails to 
disclose or suggest each limitation of claim 10 because Kumaki fails to remedy the 
deficiencies of Lord. 

Kumaki discloses a router device, datagram transfer method, and communication 
system for realizing handoff control for mobile terminals. At paragraph [0186], Kumaki 
mentions that an IP address release request is sent from a mobile terminal to an MSR, 
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similarly, at paragraph [0552], Kumaki describes how such an IP release request is 
processed. However, Kumaki fails to disclose or suggest, at least, "activating a packet 
data context for data transmission between identified participants... associating one 
packet data context with all of the internet protocol addresses of the participants ", as 
recited, in part, in claim 1, from which claim 10 depends. Because Kumaki fails to cure 
the deficiencies of Lord with respect to claim 1, Kumaki also fails to teach all of the 
subject matter recited in claim 10 which depends on claim 1. 

Therefore, it is respectfully requested that the rejection be withdrawn because the 
combination of Lord and Kumaki fails to disclose or suggest all of the elements of any of 
the presently pending claims. 

For at least the reasons discussed above, Applicants respectfully submit that the 
cited references fail to disclose or suggest all of the elements of the claimed invention. 
These distinctions are more than sufficient to render the claimed invention unanticipated 
and unobvious. It is therefore respectfully requested that all of claims 1-18 be allowed, 
and this application passed to issue. 

If for any reason the Examiner determines that the application is not now in 
condition for allowance, it is respectfully requested that the Examiner contact, by 
telephone, the applicant's undersigned representative at the indicated telephone number 
to arrange for an interview to expedite the disposition of this application. 
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In the event this paper is not being timely filed, the applicant respectfully petitions 
for an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 
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